Maybe don't mention the trait, and just write

main() can now return !, Result<(), E: Debug> and Result<!, E: Debug> in additional to ().

?

impl Trait can also appear in argument position e.g. fn open(a: impl AsRef<Path>).

wasm32-unknown-unknown.

A type that has no value

! isn't just a ZST (zero sized type), it has special powers. Can't recall what exactly they were but a better name would be "never type".

Oh BTW, if we can't find a suitable fix for #49039 (comment), we may be forced to unstabilize ! again.

I think there was a thread where it was decided that "never type" is the official, technically correct pronunciation of "! type", though unfortunately I can't find it. Since ! is how you spell it in code, I'd show both names: "Stabilised the ! type, also known as the "never" type".

"never" is what you need to search for to find it in the docs (https://doc.rust-lang.org/nightly/std/?search=never), so it would be good to include that name here.

Can't recall what exactly they were but a better name would be "never type".

Because there is no value of this type, if the compiler ever sees something with this type, it must be dead code and can be optimized out.

struct Foo; is definitely a ZST: https://doc.rust-lang.org/nomicon/exotic-sizes.html#zero-sized-types-zsts

(enum Void {} can be considered as having "size -∞" that just gets saturated to zero since the API returns usize.)

To clarify: () and struct Foo; are Zero sized types: they have exactly one possible value (() and Foo, respectively), so they can be represented with log(1) = 0 bits, hence the name. ! is not zero-sized; it cannot be represented with any number of bits because there are no values of that type.

I'd say a ZST is any type T that fulfills std::mem::size_of::<T>() == 0. And ! does fulfill it so it is zero sized. I mean when ! has a size of zero, it must be zero-sized right?

In the "abstract" type check world, both struct Foo; and enum Var{} can have values. After all you can do things like let v: ! = panic!(); let w: u32 = v; println!("{}", w + 1);.

In the "technical" code gen world, both () and ! get optimized out, their "values" never get onto the stack. The difference only shows if stuff is nested in stuff like Result, but the nomicon claims that this optimisation is not yet being performed... might be outdated given eddyb's work on it.

So I believe that the statement "a type that has no value" is neither unique to the ! type (as there are types like enum Var {}) nor is 100% accurate as as far as type checking is concerned it actually can.

And ! does fulfill it so it is zero sized.

Do you mean theoretically or in implementation? Theoretically, it should not have size zero; it's size is undefined. I don't know what the implementation of mem::size_of::<!>() does, though. I guess 0 is probably the most reasonable answer, but really None or panic! would be more correct...

@est31 There are expressions of uninhabited types (what you mean by "the type checking perspective"), but none of these expressions ever actually evaluate to a value (if they do via unsafe code, that's UB). So "no values" is an accurate if not unique description of !.

Though the specific phrasing "a type that has no value" has an unfortunate double meaning ("has no value" as in "is useless")...

typo: "fast" should be "faster"

Instead of "now accepts any type" I might say "can now return any type"

Unnecessary )..

dyn Trait isn't stable yet, so should this go in the notes?

I was wondering that myself but it was tagged with relnotes so I left it in.

@Aaronepower @steveklabnik The relnote was about a breaking change like this:

use std::ops::Fn as dyn;
fn g(_: Box<dyn(std::fmt::Debug)>) {}

Previously it compiles. Now it causes the E0658 "dyn Trait syntax is unstable" error.

oh huh

I read this as meaning that both Copy and Clone have to be implemented, thus Copy + Clone, but I think this change is also effective if the captured variables are only Clone.

I think “u128 and i128” is better than “u128 & i128”, both from a grammar (English not Rust) point of view and because the ampersand can be confused with the & operator at first glance.

This is not going to be in 1.26 😢

! should be removed from here.

TryFrom and TryInto were destabilised by #50121.

SipHasher{13,24} were never stable so there's no reason to include this change.

This is being reverted: #50401.